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ABSTRACT 



A client computer (900) and a server computer (901) com- 
municate via HTTP; the client computer (900) uses a 
standard HTTP-browser (210). Substantially simultaneously 
with establishing a session by allocating a resource (340) at 
the server computer (900), the server computer (900) sends 
a termination instruction (360) to the browser (210) during 
the whole session. In the event that the server computer 
(900) terminates the session, such as upon unloading the 
instruction (360) from the browser (210), the browser (210) 
causes the server computer (900) to de -allocate the resource 
(340). 
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1 <HTML> <HEAD> <TITLE> lnstruction-360 </TITLE> 

<script language="JavaScript"> 

2 var gs TerminalionURL-' ..." 

3 function sending_560_second_request() 

if (gsTerminalionURL != "") 
alerl{"sending_560_second_request_2/i0 : n" 
+ "Client ...:" + gsTERMINATIONURL ): 

4 function receiveSesslnfoi termURL ) 

gsTerminationllRL - termURL; 

5 </sript> </Head> 

6 <BODY onunload="sending_560_second_request()"> 

7 This is first frame 215 . The session has now started. 

8 Preferably, content frames are indicated inside a content 
frame: 

9 <1FRAME scr="content-page-335.htm" width="50%" 
height="50%" frameborder="yes" scrolling="yes" > 

10 </IFRAME> </BODY> </HTML> 



FIG. 6 
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COMMUNICATION BETWEEN CLIENT AND 
SERVER COMPUTERS VIA HTTP, METHOD, 
COMPUTER PROGRAM PRODUCT AND SYSTEM 

HELD OF THE INVENTION 
[0001] The present invention generally relates to data 
processing and, more particularly, relates to computer sys- 
tems, computer programs, and methods for communication 
between client and server computers by hypertext transfer 
protocol (HTTP) and browsers. 

[0002] Background of the Invention 

[0003] In most data communication systems, it is required 
to assure the complete transmission of information between 
two computers. 

[0004] Typically, the user operates a personal computer 
(referred to as "client computer'') that has to communicate 
with a remote computer (referred to as "server computer"). 
The client computer has communication software to com- 
municate with the server computer; the server computer has 
application software to execute a business application. 

[0005] During the communication dialog (also referred to 
as "session"), the user enters orders (e.g., for commercial 
items), issues a query (e.g., in a database), requests the 
server computer to analyze data, or performs other actions. 
During each session, the server computer allocates 
resources, for example, to store previous input data and 
intermediate results. 

[0006] Traditionally, the communication software on the 
client computer is specialized to the particular application 
software of the server computer. Often the communication 
software comprises a graphical user interface that is tailored 
to the application. Client and server computers use commu- 
nication protocols that immediately notify the server com- 
puter when the user at the client computer terminates the 
session. Before terminating, the server computer asks the 
user to save data that he or she has inputted (so-called "user 
committing"). The server computer then releases (de-allo- 
cates) the resources. 

[0007] Using specialized communication software at the 
client computer is inconvenient. Besides the time that is 
required to install it, installing the communication software 
might require the payment of license fees. Also, regular and 
costly updates are required. There is a tendency to commu- 
nicate with standard "off-the-shelf* software such as internet 
browsers. Browsers are installed in almost every personal 
computer. The hypertext transfer protocol (HTTP) became 
the standard communication protocol in the internet. How- 
ever, HTTP does not automatically notify the server com- 
puter about a session termination by the client computer. 

[0008] Typically, the server computer waits for a prede- 
termined period of time after the last client-server-commu- 
nication and then releases the resources. Keeping the 
resources allocated during this period is inconvenient, for 
example, because the resource blocks memory and slows 
down performance. 

[0009] For client-server communication, the following 
references are usefiil: U.S. Pat. No. 5,848,246 (Gish), U.S. 
Pat. No. 6,011,805 (Esteve). 

[0010] There is an ongoing need to provide improved 
computer systems, computer programs, and methods for 
communication between client and server computers that 
use HTTP-browsers. 



SUMMARY OF THE INVENTION 

[0011] The present invention provides improved client- 
server-communication, while the client computer uses a 
standard HTTP-browser. Substantially simultaneously with 
establishing a session by allocating a resource at the server 
computer, the server computer sends a termination instruc- 
tion to the browser. The instruction remains in the browser 
unexecuted during the whole session. In the event that the 
server computer terminates the session, such as upon 
unloading the instruction, the client computer causes the 
server computer to de-allocate the resource. 

[0012] As expressed in claim 1, the present invention 
relates to a method for communication between a client 
computer and a server computer in that both computers use 
HTTP. The client computer uses an HTTP-browser. The 
method comprises the following steps: 

[0013] sending a first request from the client com- 
puter to the server computer; 

[0014] upon receiving the first request, the server 
computer, (i) allocating a resource at the server 
computer, the resource with an identifier, and (ii) 
returning a predetermined close instruction to the 
browser, the close instruction carrying the identifier; 

[0015] upon unloading the close instruction firom the 
browser of the client computer, sending a second 
request ftom the client computer to the server com- 
puter, the second request carrying the identifier and 
indicating to de-allocate the resource; and 

[0016] upon receiving the second request from the 
client computer, by the server computer de-allocat- 
ing the resource. 

[0017] It is an advantage that the close instruction in the 
browser virtually couples the client computer to the server 
computer. In the event of unloading, the server computer is 
notified and is able to release the resource. Further, the 
browser is a standard browser that interprets the close 
instruction but that does not need to be modified. 

[0018] Preferably, after the server computer has returned 
the predetermined close instruction, and before the server 
computer receives the second request from the client com- 
puter, the server computer consecutively sends content 
pages to the client computer. Preferably, in the step returning 
the predetermined close instruction, the browser presents the 
close instruction in a first frame and presents the content 
pages in a second frame. Preferably, the close instruction 
prevents selected content pages ftom being cached by the 
browser. Preferably, when sending the second request, the 
client computer sends the second request to a predetermined 
address of the server computer. Preferably, in the step 
returning a predetermined close instruction, the predeter- 
mined close instruction comprises a script. Preferably, in the 
step returning a predetermined close instruction, the script 
does not lead to a presentation by the browser. 

[0019] As expressed in claim 8, the present invention 
relates to a computer program product for HTTP-commu- 
nication between a client computer and a server computer, 
wherein the client computer has a browser. The computer 
program product has program code portions that cause a 
client processor in the client computer and a server proces- 
sor in the server computer to control the communication. 
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The computer program product comprises: code portions 
that cause the client processor to send a first request to the 
server computer; code portions that — upon receiving the 
first request by the server computer — cause the server pro- 
cessor to (i) allocate a resource at the server computer, the 
resource with an identifier, and to (ii) return a predetermined 
close instruction to the browser, the close instruction carry- 
ing the identifier; code portions that — ^upon unloading the 
close instruction from the browser of the client computer — 
cause the client processor to send a second request to the 
server computer, the second request carrying the identifier 
and indicating to de-allocate the resource; and code portions 
that — ^upon receiving the second request from the client 
computer — caiise the server processor to de-allocate the 
resource. 

[0020] Preferably, the code portions cause the client pro- 
cessor to provide such a close instruction that the browser 
provides a first frame to present the close instruction in a first 
frame and provides a second frame to present content pages 
that the client computer receives from the server computer. 
Preferably, the code portions cause the client processor to 
provide such a close instruction that caching selected con- 
tent pages by the browser is prevented. Preferably, the code 
portions cause the client processor to provide such a close 
instruction that the client computer sends the second request 
to a predetermined address of the server computer. As 
expressed in claims 12 and 13, the present invention also 
relates to separate computer readable media that separately 
store the program code portions causing the client processor 
and the server processor to operate. 

[0021] As expressed in claim 14, the present invention 
relates to a computer system in that a client computer and a 
server computer use HTTP for communication and in that 
the client computer uses an HTTP-browser. The client 
computer sends a first request to the server computer; the 
server computer (upon receiving the first request) (i) allo- 
cates a resource (resource having identifier), and (ii) returns 
a predetermined close instruction to the browser of the client 
computer (the close instruction carrying the identifier); the 
client computer (upon unloading the close instruction from 
the browser) sends a second request to the server computer 
(the second request carrying the identifier and indicating to 
de-allocate the resource); and the server computer (upon 
receiving the second request from the client computer) 
de-allocates the resource. 

[0022] Preferably, the client computer presents the close 
instruction in a first frame and presents the content pages in 
a second frame. Preferably, the server computer provides the 
close instruction such that in the client computer the close 
instruction prevents selected content pages from being 
cached by the browser. 

[0023] As expressed in claim 17, the present invention 
relates to a method for communication between a client 
computer and a server computer. Both computers xise HTTP; 
the client computer uses an HTTP-browser. The client 
computer sends a request to the server computer. Upon 
receiving the request, the server computer: allocates a 
resource at the server computer (the resource with an iden- 
tifier and a time-out period), returns a close instruction to the 
client computer (the close instruction with the time-out 
period and the identifier), measiu'es the time during that 
communication between the client and serv^er computers is 



idle, and de-allocates the resource when the measured time 
reaches the time-out period. Upon receiving the close 
instruction, the client computer measures the time during 
that the communication between the client computer and the 
server computer is idle, and displays a warning to the user 
if the measured time reaches a predetermined fraction of the 
time-out period, 

[0024] It is an advantage that that unintentional lapsing the 
time-out on the client side is prevented. 

[0025] As expressed in claim 18, the present invention 
relates to a computer program product for controlling 
HTTP-communication between a client computer and a 
server computer, wherein the client computer has a browser. 
The computer program product has a client program portion 
to control a client processor and a server program portion to 
control a server processor. The program is characterized in 
that the client program product portion causes the client 
processor to send a request from the client computer to the 
server computer; upon receiving the request by the server 
computer, the server program portion causes the server 
processor to allocate a resource at the server computer 
(resource with identifier and time-out period (T)), to return 
a close instruction to the client computer (close instruction 
with time-out period (T) and identifier), to measure the time 
(t) during that communication between the client computer 
and the server computer is idle, and to de-allocate the 
resource when the measured time (t) reaches the time-out 
period (T); and upon receiving the close instruction by the 
client computer, the client program portion causes the client 
processor to measure the time (t) during that the communi- 
cation between the client computer and the server computer 
is idle, and to display a warning to the user if the measured 
time (t) reaches a predetermined fraction p/k) of the time- 
out period (T). 

[0026] As expressed in claim 19, the present invention is 
described as a method for communication between a client 
computer and a server computer, (Hi IP, client computer 
with HTTP-browser); the method comprises: sending a first 
request from the client computer to the server computer; 
allocating a resource at the server computer, the resource 
with an identifier; returning a predetermined response page 
to the browser, the response page carrying the identifier and 
carrying browser instructions; as instructed by the response 
page* periodically sending the second requests by the 
browser to the server computer, the second requests carrying 
the identifier; and at the server computer, periodically check- 
ing the arrival of the second requests with the identifier from 
the client computer and de-allocating the resource in case a 
predetermined time period (T) has lapsed since the last 
arrival. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0027] FIG. 1 illustrates a simplified block diagram of a 
computer network system having a plurality of computers; 

[0028] FIG, 2 illustrates a simplified block diagram of the 
system in that a client computer and a server computer 
communicate with each other; 

[0029] FIG. 3 illustrates a simplified flow chart diagram 
of a method of the present invention; 

[0030] FIG. 4 illustrates a display of the client computer 
for that a browser shows a first frame and a second frame; 
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[0031] FIG. 5 illustrates a simplified state diagram for a 
resource that is allocated in the server computer; 

[0032] FIG. 6 is a simplified code listing of an instruction 
that participates in the method of FIG. 3; 

[0033] FIG. 7 illustrates a simplified diagram of the 
method of the present invention in a further embodiment by 
way of example; 

[0034] FIG. 8 illiistrates simplified diagrams of content 
pages at a previous time point, at an actual time point and at 
a future time point; 

[0035] FIG. 9 illustrates a simplified diagram of the 
computer system in further optional method implementa- 
tions; and 

[0036] FIG. 10 illustrates a simplified flow-chart diagram 
of the method of the present invention in a still further 
embodiment. 

DETAILED DESCRIPTION OF THE 
INVENTION 

[0037] For convenience, a list of references is provided 
prior to the claims. Logical addresses (e.g., URL) are 
indicated in quotation marks and conveniently cite the 
addressed element by its name and reference number; such 
as "server-computer-901" being an address for server com- 
puter 901. 

[0038] FIG. 1 illustrates a simplified block diagram of 
computer network system 999 having a plurality of com- 
puters 900, 901, 902 (or 90^, with q=0 . . . Q-1, Q any 
number). 

[0039] Computers 900-902 are coupled via inter-computer 
network 990. Computer 900 comprises processor 910, 
memory 920, bus 930, and, optionally, input device 940 and 
output device 950 (I/O devices, user interface 960). As 
illustrated, the invention is present by computer program 
product 100 (CPP), program carrier 970 and program signal 
980, collectively "program". 

[0040] In respect to computer 900, computer 901/902 is 
sometimes referred to as "remote computer", computer 
901/902 is, for example, a server, a router, a peer device or 
other common network node, and typically comprises many 
or all of the elements described relative to computer 900. 
Hence, elements 100 and 910-980 in computer 900 collec- 
tively illustrate also corresponding elements 10^ and 91^- 
98^ (shown for q=0) in computers 90^. 

[0041] Computer 900 is, for example, a conventional 
personal computer (PC), a desktop and hand-held device, a 
multiprocessor computer, a pen computer, a microprocessor- 
based or programmable consumer electronics, a minicom- 
puter, a mainframe computer, a personal mobile computing 
device, a mobile phone, a portable or stationary personal 
computer, a palmtop computer or the like. 

[0042] Processor 910 is, for example, a central processing 
unit (CPU), a micro-controller unit (MCU), digital signal 
processor (DSP), or the like. 

[0043] Memory 920 symbolizes elements that temporarily 
or permanently store data and instructions. Although 
memory 920 is conveniently illustrated as part of computer 
900, memory function can also be implemented in network 



990, in computers 901/902 and in processor 910 itself (e.g., 
cache, register), or elsewhere. Memory 920 can be a read 
only memory (ROM), a random access memory (RAM), or 
a memory with other access options. Memory 920 is physi- 
cally implemented by computer-readable media, such as, for 
example: (a) magnetic media, like a hard disk, a floppy disk, 
or other magnetic disk, a tape, a cassette tape; (b) optical 
media, like optical disk (CD-ROM, digital versatile disk — 
DVD); (c) semiconductor media, hke DRAM, SRAM, 
EPROM, EEPROM, memory stick, or by any other media, 
like paper. 

[0044] Optionally, memory 920 is distributed across dif- 
ferent media. Portions of memory 920 can be removable or 
non-removable. For reading from media and for writing in 
media, computer 900 uses devices well known in the art 
such as, for example, disk drives, tape drives. 

[0045] Memory 920 stores support modules-such as, for 
example, a basic input output system (BIOS), an operating 
system (OS), a program library, a compiler, an interpreter, 
and a text-processing tool. Support modules are commer- 
cially available and can be installed on computer 900 by 
those of skill in the art. For simplicity, these modules are not 
illustrated. 

[0046] CPP 100 comprises program instructions and — 
optionally — data that cause processor 910 to execute method 
steps of the present invention. Method steps are explained 
with more detail below. In other words, CPP 100 defines the 
operation of computer 900 and its interaction in network 
system 999. For example and without the intention to be 
limiting, CPP 100 can be available as source code in any 
programming language, and as object code ("binary code") 
in a compiled form. Persons of skill in the art can use CPP 
100 in connection with any of the above support modules 
(e.g., compiler, interpreter, operating system). 

[0047] Although CPP 100 is illustrated as being stored in 
memory 920, CPP 100 can be located elsewhere. CPP 100 
can also be embodied in carrier 970. 

[0048] Carrier 970 is illustrated outside computer 900. For 
communicating CPP 100 to computer 900, carrier 970 is 
conveniently inserted into input device 940. Carrier 970 is 
implemented as any computer readable medium, such as a 
medium largely explained above (cf. memory 920). Gener- 
ally, carrier 970 is an article of manufacttu'e comprising a 
computer readable medium having computer readable pro- 
gram code means embodied therein for executing the 
method of the present invention. Further, program signal 980 
can also embody computer program 100. Signal 980 travels 
on network 990 to computer 900. 

[0049] Having described CPP 100, program carrier 970, 
and program signal 980 in connection wilh-computer 900 is 
convenient. Optionally, program carrier 971/972 (not 
shown) and program signal 981/982 embody computer 
program product (CPP) 101/102 to be executed by processor 
911/912 (not shown) in computers 901/902, respectively. 

[0050] Input device 940 symbolizes a device that provides 
data and instructions for processing by computer 900. For 
example, device 940 is a keyboard, a pointing device (e.g., 
mouse, trackball, cursor direction keys), microphone, joy- 
stick, game pad, scanner. Although the examples are devices 
with human interaction, device 940 can also operate without 
human interaction, such as, a wireless receiver (e.g., with 
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satellite dish or terrestrial antenna), a sensor (e.g., a ther- 
mometer), a counter (e.g., goods counter in a factory). Input 
device 940 can serve to read carrier 970. 

[0051] Output device 950 symbolizes a device that pre- 
sents instructions and data that have been processed. For 
example, a monitor or a display, (cathode ray tube (CRT), 
flat panel display, liquid crystal display (LCD), speaker, 
printer, plotter, vibration alert device. Similar as above, 
output device 950 communicates with the user, but it can 
also communicate with further computers. 

[0052] Input device 940 and output device 950 can be 
combined to a single device; any device 940 and 950 can be 
provided optional. 

[0053] Bus 930 and network 990 provide logical and 
physical connections by conveying instruction and data 
signals. While coimections inside computer 900 are conve- 
niently referred to as "bus 930*', connections between com- 
puters 900-902 are referred to as "network 990". Optionally, 
network 990 comprises gateways being computers that 
specialize in data transmission and protocol conversion. 

[0054] Devices 940 and 950 are coupled to computer 900 
by bus 930 (as illustrated) or by network 990 (optional). 
While the signals inside computer 900 are mostly electrical 
signals, the signals in network are electrical, magnetic, 
optical or wireless (radio) signals. 

[0055] Networking environments (as network 990) are 
commonplace in offices, enterprise-wide computer net- 
works, intranets and the internet (i.e. world wide web). The 
physical distance between a remote computer and computer 

900 is not important. Network 990 can be a wired or a 
wireless network. To name a few network implementations, 
network 990 is, for example, a local area network (LAN), a 
wide area network (WjW), a public switched telephone 
network (PSTN); a Integrated Services Digital Network 
(ISDN), an infra-red (IR) link, a radio link, like Universal 
Mobile Telecommunications System (UMTS), Global Sys- 
tem for Mobile Communication (GSM), Code Division 
Multiple Access (CDMA), or satellite link. 

[0056] Transmission protocols and data formats are 
known, for example, as transmission control protocol/inter- 
net protocol (TCP/IP), hyper text transfer protocol (HTTP), 
secure HTTP, wireless application protocol, unique resource 
locator (URL), a unique resource identifier (URI), hyper text 
markup language HTML, extensible markup language 
(XML), extensible hyper text markup language (XHTML), 
wireless application markup language (WML), etc. 

[0057] Interfaces coupled between the elements are also 
well known in the art. For simplicity, interfaces are not 
illustrated. An interface can be, for example, a serial port 
interface, a parallel port interface, a game port, a universal 
serial bus (USB) interface, an internal or external modem, a 
video adapter, or a sound card. Computer and program are 
closely related. As used hereinafter, phrases, such as "the 
computer provides" and "the program provides", are con- 
venient abbreviation to express actions by a computer that is 
controlled by a program. 

[0058] FIG. 2 illustrates a simplified block diagram of 
system 999 in that client computer 900 and server computer 

901 communicate with each other via network 990 (branch 
990-1). Both computers 900 and 901 use the hypertext 



transfer protocol (HTTP); client computer 900 further uses 
HTTP-browser 210. Browser 210 is the program to locate 
content pages (e.g., in computer 901) and to display the 
content pages (presentation 211, cf. FIG. 4). Preferably, 
browser 210 presents graphics as well as text. Preferably, 
browser 210 is a Netscape Navigator or a Microsoft Internet 
Explorer. 

[0059] Usually, server computer 901 executes business 
application 401. It is an advantage of the present invention, 
that browser 210 is software that is commercially available 
as a standard browser. In other words, computer 900 does 
not require special software that is dedicated for communi- 
cation with application 401 in computer 901, 

[0060] During normal operation, browser 210 requests 
content pages from server computer 901, server computer 
901 responds with content (e.g., HTML pages), browser 210 
then causes display 950 to show content pages to the user. 
An exemplary content page 335 is symbolized by an excla- 
mation mark. 

[0061] Similar elements such as display, memory, proces- 
sor, etc. for the other computers are not illustrated for 
simplicity. Optionally, client computer 900 also communi- 
cates with computers 902 and 903 via branches 990-2 and 
990-3, respectively; computers 902 and 903 execute appli- 
cations 402 and 403, respectively. Optionally, the content 
pages are generated by application computer 902. Likewise, 
browser 210 requests pages from application computer 902, 
application computer 902 responds with application pages. 

[0062] Preferably, application 403 assists the user to iden- 
tify apphcation 401 and 402 out of a plurality of applications 
that are available in the overall network. Such assistance 
applications are commercially available from SAP Aktieng- 
esellschaft, Walldorf (Baden), Germany under the name 
"workplace". For convenience, computer 903 is therefore 
referred to as "workplace computer". Further illustrated 
elements are: resource 340 (used temporarily), requests 230, 
240, instruction 360 and ID 350 (transmitted via the net- 
work). The function of these elements is explained next: 

[0063] FIG. 3 illustrates a simplified flow chart diagram 
of method 500 of the present invention. Method 500 is a 
method of communication between client computer 900 and 
server computer 901. Both computers 900, 901 use the 
hypertext transfer protocol (HTTP); client computer 900 
uses HTTP-browser 210. 

[0064] Method 500 comprises the following steps: send- 
ing 520 a first request, allocating 531 a resource, returning 
532 a close instruction, sending 560 a second request, and 
de-allocating 580 the resource. Executing the steps depends 
on predefined conditions; for convenience of explanation, 
FIG. 3 illustrates the conditions by query symbols and 
YES/NO questions: upon receiving 530 the first request 
(received ?), upon unloading 540 the close instruction 
(unloaded ?), and upon receiving 570 the second request 
(received ?). If the conditions are met, the execution of 
method 500 continues (Y-YES), otherwise, the execution of 
method 500 is suspended (N-NO). 

[0065] Although referred to as communication between 
client computer 900 and server computer 901, communica- 
tion can also occur between client computer 900 and com- 
puters 902/903. 
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[0066] The steps are now explained in detail: 

[0067] In step sending 520, client computer 900 sends first 
request 230 to server computer 901, Preferably, first request 
230 is a unified resource locator (URL) by that client 
computer 900 identifies business application 401 on server 
computer 901 (e.g., "http://network-990/server-computer- 
901/application-401"). First request 230 is also referred to as 
"client session command" and is also referred to by the 
acronym "USR_OPEN". 

[0068] Preferably, first request 230 informs server com- 
puter 901 that client computer 900 operates according to 
method 500. During sending 520, a session is not yet 
initiated because a session ID is not yet created. 

[0069] Server computer 901 performs steps 531 and 532 
upon receiving 530 first request 230. 

[0070] In step allocating 531, server computer 901 allo- 
cates resource 340 (at server computer 901). Resource 340 
has identifier 350 (session identification). Resource 340 is 
sometimes referred to as "session state". Resource 340 uses 
memory 921 (cf. explanation of FIG. 1). Identifier 350 is 
sometimes referred to as "global unique session ID". For 
example, identifier 350 comprises a text portion with the 
name of server computer 901 and a numeric portion (<server 
namexsession ID>). 

[0071] The present invention is described in connection 
with a single resource 340, a single session and a single 
identifier 350, persons of skill in the art are able to imple- 
ment two or more sessions in parallel. 

[0072] As used herein, the term "allocate a resource" 
comprises that server computer 901 stores previous input 
data and intermediate results. 

[0073] In step returning 532, server computer 901 returns 
predetermined close instruction 360 to browser 210. Pref- 
erably, close instmction 350 is implemented as a HTML- 
page that comprises a script (e.g., JavaScript) or a program 
(e.g., JavaApplet). An example is explained in connection 
with FIG. 6. Qose instruction 360 carries identifier 350. 
Carrying identifier 350 can be accomplished by means well 
known in the art. For example, identifier 350 is carried as 
part of a URL or by a cookie. Reception of identifier 350 by 
client computer 900 marks the start of a communication 
session (FIG. 3: SESSION_START), because firom now on 
both, client computer 900 and server computer 901, use 
identifier 350 that is related to resource 340. 

[0074] As mentioned, client computer 900 performs step 
560 upon unloading 540 close instruction 360 from browser 
210. The phrase "upon unloading" is intended to comprise 
the following: 

[0075] (1) The user closes browser 210; persons of skill 
in the art are able to detect this. In the example, 
explained in connection with FIG. 6, section 6, closing 
the browser is detected by the script event "onbefore 
unload" or "onunload". 

[0076] (2) From the page that implements close instruc- 
tion 360, the user navigates away to another page. In 
other words, a new page displaces the old page (cf. 
FIG. 4, for example, by writing a new address into field 
214). 



[0077] It is also possible — although not required for the 
present invention — that the user terminates the session 
explicitly, for example, by operating a fiinctional button 
such as an "abort session" button (cf. 217, 218219 in FIG. 
4 or similar ones). 

[0078] In step sending 560, client computer 900 sends 
second request 240 to server computer 901. Second request 
240 carries identifier 350. Optionally, second request 240 is 
initiated by direct user interaction, for example, by activat- 
ing a dedicated button. Second request 240 requires valid 
identifier 350. Sending 560 second request 240 is the defined 
way of notifying server computer 901 that client computer 
900 terminates the session. 

[0079] Server computer 901 performs step 580 upon 
receiving 570 second ■ request 240. Second request 240 is 
understood by server computer 901 so that in step de- 
allocating 580, server computer 901 de-allocates resource 
340. De-allocating is the opposite of allocating; server 
computer 901 discards previous input data (e.g., from the 
user) and intermediate results (e.g., of application 401). 

[0080] Optionally, de-allocating comprises that server 
computer 901 transfers input data and intermediate results to 
other memory areas that are reserved for application 401. 
This is often the case when application 401 responds to a 
user request to place an order for a commercial item and the 
user finishes a business transaction. 

[0081] When resource 340 has been de-allocated from 
server computer 901, the session has come to its end (FIG. 
3: SESSION_END). Server computer 901 does not need to 
send a response to second request 240 to client computer 
900. Optionally, server computer 901 responds by a mini- 
mum response (e.g., "<HTML></HTML>") 

[0082] FIG. 4 illustrates display 950 of client computer 

900 for that HTTP-browser 210 (cf. FIG. 2) generates 
browser presentation 211. Browser presentations are well 
known in the art; in the example of FIG. 4, presentation 211 
has back button 213, address field 214, and close button 219, 
warning 205 and a display area for showing frames. 

[0083] According to a preferred embodiment, presentation 
211 shows first frame 215 and second frame 216, each 
having close buttons 217 and 218, respectively. Since, 
preferably, frame 215 is presented prior to frame 216, the 
frames are also referred to as parent frame 215 and child 
firame 216. Browser 210 implements close instruction 360 
into first frame 215. Displaying frame 215 is optional. 

[0084] Address field 214 shows the HTTP-address (URL) 
of content 335: "http://network-990/server-computer-901/ 
applicalion-401/content-335". Browser 210 has requested 
content page 335 by forwarding the mentioned URL to 
server computer 901. Browser 210 shows content page 335 
(exclamation mark symbol) received from server computer 

901 (e.g., from application 401) in second frame 216. Frame 
216 is conveniently an integrated frame IFRAME. 

[0085] Splitting the display screen into frames 215, 216 is 
convenient for the user: Frame 215 informs that session 
management (cf. method 500) is active, for example, by 
informing that the user can now access application 401 (e.g., 
"APPUCAnON READY"). 

[0086] FIG. 4 also conveniently illustrates exit buttons 
217, 218, 219 by X-symbols. If the user operates either one. 
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browser 210 detects this as unloading 540 (cf . FIG, 3). This 
is an advantage of the present invention. The user is free to 
close a frame (button 217, 218) or even to close browser 210 
(button 219) at any time, and the further steps 560-580 
terminate the session. 

[0087] Warning 205 is optional and informs the user that 
browser 210 is sending out second request 240. In the 
example of FIG. 4, warning 205 appears after the user has 
caused the unloading event (cf. FIG. 3, 540), and warning 
205 asks the user for confirmation. 

[0088] FIG. 5 illustrates a simplified state diagram for 
resource 340 that is allocated or de-allocated in server 
computer 901. As mentioned, performing method 500 leads 
to allocate or to de-allocate resource 340. As indicated by 
plain arrows, first request 230 leads to the state 1 "allocated" 
(also: "state-full") and second request 240 leads to the state 
0 "de-allocated" ("state-less"). 

[0089] Optionally, indicated by dashed arrows, de-alloca- 
tion can be triggered by a request ("SRV_CLOSE") from 
application 401. In this case, server computer 901 notifies 
browser 210 in client computer 900 to remove ("session 
closed information") instruction 360 from browser 210 or to 
re-direct browser 210. 

[0090] Performing session management by method 500 
can be (a) central session management, or (b) distributed 
session management. 

[0091] In case (a), close instruction 360 is part of a session 
manager that resides on client computer 900 and that is, 
preferably, responsible for multiple sessions. In other words, 
such a session manager performs the method steps in 
parallel for multiple applications (such as 401 or 402) for 
multiple resources (such as 340) by receiving multiple 
instructions (such as 360) in parallel. Optionally, code to 
perform the method steps is forwarded to client computer 
900 from worlqjlace computer 903. In other words, server 
computer 901 (or application computer 902) cooperates with 
workplace computer 903 to provide multiple identification 
for these multiple resources. 

[0092] When frames are used, preferably, a single parent 
frame (e.g., frame 215, FIG. 4) has multiple child frames 
(e.g., frame 216) for each resource (also referred to as 
"workspaces" or "channels"). The present invention allows 
to scale session management to multiple computers, appli- 
cations and resources. 

[0093] In case (b), client computer 900 receives instruc- 
tion 360 from server computer 901. The following example 
in connection with FIG. 6 uses a close instruction that is 
created for each session. 

[0094] FIG. 6 is a simplified code listing of instruction 
360. Browser 210 conveniently loads instruction 360 into a 
parent frame. Displaying the parent frame conveniently 
informs the user that session management is active. But 
displaying the frame is not important. 

[0095] For convenience of explanation herein, multiple 
instructions are sometimes placed on single lines whereas 
programmers would have placed them on separate lines. 
This is especially true for well-known syntax. 

[0096] Code section 1 defines HTML as language, a head 
portion (sections 1-4), a title that is conveniently chosen as 
"instruction-360'*, as well as defines the script language 
JavaScript. 



[0097] Code section 2 defines a global string to store 
second request 240 (referred to as "termination URL") for 
the session in child frame 216. In the example, request 240 
does not have any other content; is it sufiBcient to target 
second request 240 by identifier 350 to an address in server 
computer 901 that is reserved for de-allocating resource 340 
(for example, http://networic-990.server-computer-901.ap- 
plication-401.resource-340") 

[0098] Code section 3 defines a function 
"sending_560_second_request( )" that implements step 560. 
For convenience of explanation, the function further dis- 
plays a message with the complete text "Client . . . ". The 
message reads as: "Client computer 900 is now sending 560 
second request 240 to server computer 901. Second request 
240 is the following URL ..." 

[0099] Code section 4 defines a function to store received 
session identifier 350 (here: identifier contains only the 
termination URL). 

[0100] Code section 5 closes the above script and head 
sections. 

[0101] Code section 6 defines "upon unloading 540" by 
the event "onunload" and defines that step 560 is then 
executed. 

[0102] Code section 7 is not required for the present 
invention. For convenience of explanation, section 7 pro- 
vides a display that reports method steps that took place in 
the past: 

[0103] "This is first frame 215. Client computer 900 with 
browser 210 had been sending 520 first request 230 (e.g., by 
URL "http://network-990/server-computer-901/application- 
401") to server computer 901. Upon receiving 530 first 
request 230, server computer 901 had been allocating 531 
resource 340 with identifier 350 and had been returning 532 
predetermined close instruction 360 in the form of the 
present HTML-document "instruction-360.htm" with iden- 
tifier "340". Close instruction 360 carries identifier 350 
("340"). HTML-document "instruction-360.htm" comprises 
a termination command in the program section 6 with 
"onunload". The session has now started. 

[0104] Code Section 8 is optionally and informs the user 
that content pages 335 are indicated inside a content frame. 

[0105] Code section 9 is also optional and identifies con- 
tent page 335 as an IFRAME to display a HTML-file at a 
given address. IFRAMES are well known in the art. 

[0106] Code section 10 provides conventional HTML- 
syntax. 

[0107] The following explains advanced session manage- 
ment features (c) "timer" and (d) "cache prevention" that are 
optionally implemented according to the present invention. 

[0108] The advanced session management feature (c) 
"time" is explained: 

[0109] FIG. 7 illustrates a simplified diagram of a method 
of the present invention in a further embodiment by way of 
example. Method 600 for communication between client 
computer 900 and server computer 901 (symbolized by 
vertical lines) via HTTP (computer 900 with HTTP-browser 
210) comprises the following steps: 
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[0110] sending 601 first request 230 from client com- 
puter 900 to server computer 901 (symbolized by an 
arrow to the right); upon receiving 611 (point sym- 
bol) first request 230, server computer 901 (right 
line) executes the steps allocating 612 resource (cf. 
step 531 in FIG. 3), returning 613 close instruction 
(cf. step 532), measuring 614 time and de-allocating 
614 resource (cf. step 580); and upon receiving 602 
close instruction, client computer 900 (left line) 
executes the steps measuring 603 lime, and display- 
ing 604 warning. 

[0111] Details for the steps at server computer 901 are as 
follows: 

[0112] In step allocating 612, server computer 901 allo- 
cates resource 340 (cf. FIG. 2), resource 340 has identifier 
350 (e.g., URL to resource 340) and has a time-out period T. 
In the example, the period T is 60 seconds corresponding to 
a full pointer turn in a simplified clock symbol. In step 
returning 613, server computer 901 returns close instruction 
360 to client computer 900 (similar as described by the other 
figures). Close instruction 360 also transfers a representation 
of timeout period T (e.g., a number "60" at a predetermined 
location in HTML) and transfers identifier 350. In step 
measuring 614, server computer 901 measures the time t 
during that communication between client computer 900 and 
server computer 901 is idle. In FIG. 7, t is 15 seconds. The 
term "idle" as used herein is intended to describe the absence 
of content page requests from client computer 900 that 
access resource 340 in the present session (as defined in 
connection with FIG. 3); communication that relates to 
other applications is not considered here. In step de-allocat- 
ing 615, server computer 901 de -allocates resource 340 
when the measured time t reaches time-out period T, for 
example after 60 seconds (from receiving 611). 

[0113] Details for the steps at client computer 900 are as 
follows: In step measuring 603, client computer 901 mea- 
sures the time t during that the commimication between 
client computer 900 and server computer 901 is idle. In step 
displaying 604, client computer 901 issues a warning (orally 
or visually, e.g., similar to 205 in FIG. 4) to the user if 
measured time t reaches a predetermined fraction % of the 
time-out period T. In the example (X«^/6), the fraction is 
reached after 45 seconds. Since identification 360 of 
resource 340 has been transmitted to client computer 900, 
the user can now respond by communicating with server 
computer 901 to refresh (set t=0). 

[0114] The advanced session management feature (d) 
"cache prevention" is explained: 

[0115] FIG. 8 illustrates simphfied diagrams of content 
pages 335 at a previous time point (t-1), at an actual time 
point (t) and at a future time point (t+1). Browser 210 
usually has back button 213 (often named "BACK", cf. FIG. 
4), and browser 210 allocates a cache (not illustrated) in 
memory 920 to temporarily store content pages 335. 

[0116] When the user presses back button 213, browser 
210 changes the display from actual content page 335 at 
actual time point (t) to previous content page 335 at previous 
time point (t-1). 

[0117] As long as application 401 in server computer 901 
is a read-only type application and content pages 335 
substantially remain unchanged, displaying cached pages is 



convenient. In some instances, especially for business appli- 
cations, intermediate results stored in resource 340 at server 
computer 901 diverge from temporarily cached content 
pages 335(r-l) on client computer 900. This is no longer 
convenient and might cause serious problems: 

[0118] For example, application 401 is a shopping appli- 
cation. The user has located some items ABC into an 
shopping basket icon on content page 335(/). Resource 340 
(cf. FIG. 2) stores ABC; previous content page 335(r-l) in 
the cache comprises ABC as weU, The user now completes 
the shopping transaction and therefore requests a further 
content page with payment procedures (not illustrated). Now 
the user, most likely being influenced by the total payable 
amount for ABC, removes item C from the basket icon: 
application 401 returns content page 335(/+l) that shows 
AB; resource 340 (cf. FIG. 2) stores AB as well. The user 
now unintentionally presses back button 213 but sees cached 
page 335(f-l) with ABC. Now the display ABC on client 
computer 900 and intermediate results AB in server com- 
puter 901 are different. 

[0119] According to the present invention, optionally, 
close instruction 360 prevents content pages 335 from being 
cached by browser 210. This is illustrated by dashed lines 
crossing out content page 335(/-l). Even if the user presses 
back button 213, content pages are reloaded from server 
computer 900 (here: AB). It is convenient not to apply this 
rule to all content pages 335. Preferably, server computer 
901 distinguishes cache-prevented content pages 335 from 
cache-allowed content pages 335 by attaching tags or by 
other means. 

[0120] The following describes an optional implementa- 
tion (e) of distributed session management: 

[0121] FIG. 9 illustrates a simplified diagram of computer 
system 999 for further optional method implementations. 
Illustrated are computers 900, 901 and 903. Applications are 
distinguished into main (M) and starter (S) applications, 
addressed by equal domain names. By providing close 
instructions, the starter applications (S) provide session 
management functionality according to the present inven- 
tion (methods 500 and 600). The example of FIG. 9 is 
simplified to application 401; persons of skill in the art can 
use the same scheme for multiple applications (with differ- 
ent domains) in parallel and independent from each other. 

[0122] (1) The user (of client computer 900) sends a 
URL to the assistance application 403 (the "work- 
place") on workplace computer 903 ("http://net- 
work-990 . . . computer-903-/application-403"). 

[0123] (2) Application 403 forwards content pages to 
browser 210 on client computer 900; the pages offer 
a number of applications, such as main application 
401-M. A hyperlink goes to the corresponding starter 
application 401-S. (http://network-990 . . . applica- 
tion-401-S"). Application 401-S is a starter for appli- 
cation 401-M (in computer 900). The domain 
"server-computer-901" is identical for starter appli- 
cation 401-S and main application 401-M. 

[0124] (3) The user-selects the hyperlink to applica- 
tion 401-S; client computer 900 sends request 230 to 
server computer 901. 

[0125] (4) Starter application 401-S allocates 
resotirce 340 (cf. step 531) and returns (cf. step 532) 
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instruction 360 to client computer 900; instruction 
360 has session management code (e.g., as in FIG. 
6, code sections 3, 6). 

[0126] (5) Instruction 360 has code that instructs 
browser 210 to open IFRAME (e.g., similar as in 
FIG. 6, code section 9). IFRAME is associated with 
a link to main application 401-M (not to the starter, 
but to the application itself). The user now interacts 
with main application 401-M. 

[0127] (6) Upon unloading (cf. condition 540), 
browser 210 sends second request 240 to starter 
application 401-S that de-allocates resource 340 and 
interacts with application 401-M. 

[0128] The following describes a still further optional 
embodiment (f): 

[0129] FIG. 10 illustrates a simplified flow-chart diagram 
of the method of the present invention in a still further 
embodiment. Method 700 for communication between client 
computer 900 and server computer 901 (HTTP, client with 
browser 210) comprises the following steps: sending 720 
first request 230 &om client computer 900 to the server 
computer 901 (cf. FIG. 2); allocating 731 resource 340 at 
the server computer 901 (cf. FIG. 2), resource 340 with 
identifier 350 (Cf. FIG. 2); returning 732 a predetermined 
response page (similar as instruction 360) to browser 210, 
the response page carrying identifier 350 and carrying 
browser instructions; as instructed by the response page, 
periodically sending 760 second requests 240 (cf. FIG. 3) by 
browser 210 to server computer 901 (second requests 240 
carrying the identifier 350); and at server computer 901, 
periodically checking 770 the arrival of second requests 240 
with the identifier 350 ("ARRIVED IN TIME ?") from client 
computer 900 and de -allocating 780 resource 340 in case a 
predetermined time period (T) has lapsed since the last 
arrival ("ARRIVED IN TIME ? NO"). 

[0130] If the responses arrive in time ("YES"), resource 
340 remains allocated. This preferred embodiment allows to 
de-allocate a resource even if client computer is not longer 
in operation (e.g., after a crash). Optionally, step de-allocat- 
ing 780 is performed after confirmation by the user. 

[0131] The present invention can also be considered as 
computer program product (CPP) 100/101 for HTTP-com- 
munication between client computer 900 and server com- 
puter 901. Program product (100/101) has program code 
portions 100 that cause client processor 910 (cf. FIG. 1) in 
client computer 900 and program code portions 101 in 
server processor 911 in server computer 901 (cf. explanation 
of FIG. 1) to control the communication as described in 
method 500/600/700. The foregoing description is also 
applicable for computer system 999 in that client computer 
9(M) and server computer 901 communicate as described. 
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1. A method (500) for communication between a client 

List of References Computer (900) and a server computer (901), both comput- 

~ — £-£i£S££S_ ^^^^ ^j^g jjjg ijypertext transfer protocol (HTTP), 

Reference Element the client computer (900) using an HTTP-browser (210); 

1, 2, 3, ... 10 code sections the method (500) comprising the following steps: 

100 client program portion of 

CPP sending (520) a first request (230) from the client 

computer (900) to the server computer (901); 
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upon receiving (530) the first request (230), the server 
computer (901), (i) allocating (531) a resource (340) 
at the server computer (901), the resource (340) with 
an identifier (350), and (ii) retiiming (532) a prede- 
termined close instruction (360) to the browser 
(210), the close instruction (360) carrying the iden- 
tifier (350); 

upon unloading (540) the close instruction (360) from 
the browser (210) of the client computer (900), 
sending (560) a second request (240) from the client 
computer (900) to the server computer (901), the 
second request (240) carrying the identifier (350) and 
indicating to de-allocate the resource (340); and 

upon receiving (570) the second request (240) firom the 
client computer (900), by the server computer (901) 
de-allocating (580) the resource (340). 

2. The method (500) of claim 1, wherein after the server 
computer (901) has returned (532) the predetermined close 
instruction (360), and before the server computer (901) 
receives (570) the second request (240) from the client 
computer (900), the server computer (901) consecutively 
sends content pages (335) to the client computer (900). 

3. The method (500) of claim 2, wherein in the step 
returning (532) a predetermined close instruction (360), the 
browser (210) presents the close instruction (360) in a first 
frame (215) and presents the content pages (335) in a second 
frame (216). 

4. The method (500) of claim 2, wherein the close 
instruction (360) prevents selected content pages (335) fi'om 
being cached by the browser (210). 

5. The method (500) of claim 1, wherein in the step 
sending (560) a second request (240), the client computer 
(900) sends the second request (240) to a predetermined 
address of the server computer (901). 

6. The method (500) of claim 1, wherein in the step 
returning (532) a predetermined close instruction, the pre- 
determined close instruction (360) comprises script (1-5). 

7. The method (500) of claim 1, wherein in the step 
returning (532) a predetermined close instruction, the script 
does not lead to a presentation by the browser (210). 

8. A computer program product (100/101) for HTTP- 
communication between a client computer (900) and a 
server computer (901), wherein the client computer (900) 
has a browser (210), the computer program product (100/ 
101) having program code portions that cause a client 
processor (910) in the client computer (900) and a server 
processor (911) in the server computer (901) to control the 
communication, the computer program product (100/101) 
comprising: 

code portions that cause the client processor (910) to send 
(520) a first request (230) to the server computer (901); 

code portions that — upon receiving (530) the first request 
(230) by the server computer (901)— cause the server 
processor (911) to (i) allocate (531) a resource (340) at 
the server computer (901), the resource (340) with an 
identifier (350), and to (ii) return (532) a predetermined 
close instruction (360) to the browser (210), the close 
instruction (360) carrying the identifier (350); 

code portions that — upon unloading (540) the close 
instruction (360) from the browser (210) of the client 
computer (900)-K;ause the client processor (910) to 
send (560) a second request (240) to the server com- 



puter (901), the second request (240) carrying the 
identifier (350) and indicating to de-allocate the 
resource (340); and 

code portions that — upon receiving (570) the second 
request (240) from the client computer (900) — cause 
the server processor (911) to de-allocate (580) the 
resource (340). 

9. The computer program product (100/101) of claim 8, 
wherein the code portions cause the client processor (900) to 
provide such a close instruction (360) that the browser (210) 
provides a first frame (215) to present the close instruction 
(360) in a first frame and provides a second frame (216) to 
present content pages (335) that the client computer (900) 
receives firom the server computer (900). 

10. The computer program product (100/101) of claim 8, 
wherein the code portions cause the client processor (900) to 
provide such a close instruction (360) that caching selected 
content pages (335) by the browser (210) is prevented. 

11. The computer program product (100/101) of claim 8, 
wherein the code portions cause the client processor (900) to 
provide such a close instruction (360) that the client com- 
puter (900) sends the second request (240) to a predeter- 
mined address of the server computer (901). 

12. A computer readable medium (970) storing the pro- 
gram code portions of the computer program product (100) 
of claim 8 that cause the client-processor (910) to operate. 

13. A computer readable medium (971) storing the pro- 
gram code portions of the computer program product (101) 
of claim 8 that cause the server processor (911) to operate. 

14. A computer system (999) in that a client computer 
(900) and a server computer (901) use HTTP for commu- 
nication and in that the client computer (900) uses an 
HTTP-browser (210); the computer system (999) character- 
ized in that: 

the client computer (900) sends (520) a first request (230) 
to the server computer (901); 

the server computer (901), upon receiving (530) the first 
request (230), (i) allocates (531) a resource (340), the 
resource (340) having an identifier (350), and (ii) 
returns (532) a predetermined close instruction (360) to 
the browser (210) of the client computer (900), the 
close instruction (360) carrying the identifier (350); 

the client computer (900), upon unloading (540) the close 
instruction (360) from the browser (210), sends (560) a 
second request (240) to the server computer (901), the 
second request (240) carrying the identifier (350) and 
indicating to de-allocate die resource (340); and 

the server computer (901), upon receiving (570) the 
second request (240) from the client computer (900), 
de-allocates (580) the resource (340). 

15. The computer system (999) of claim 14, wherein the 
client computer (900) presents the close instruction (360) in 
a first fi-ame (215) and presents the content pages (335) in a 
second frame (216). 

16. The computer system (999) of claim 14, wherein the 
server computer (901) provides the close instruction (360) 
such that in the client computer (900) the close instruction 
(360) prevents selected content pages (335) fi-om being 
cached by the browser (210). 

17. A method (600) for communication between a chent 
computer (900) and a server computer (901), both comput- 
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ers (900, 901) using the hypertext transfer protocol (HTTP), 
the client computer (900) using an HTTP-browser (210); 

the method (600) comprising the following steps: 

sending (601) a request (230) from the client computer 
(900) to the server computer (901); 

upon receiving (611) the request (230), the server 
computer (901): 

allocating (612) a resource at the server computer 
(901), the resource with an identifier (350) and a 
time-out period (T), 

returning (613) a close instruction (360) to the cHent 
computer (900), the close instruction (360) with 
the time-out period (T) and the identifier (350), 

measuring (614) the time (t) during that communi- 
cation between the client computer (900) and the 
server computer (901) is idle, and 

de-allocating (615) the resource (340) when the 
measTired time (t) reaches the time-out period (T); 
and 

upon receiving (602) the close instruction (360), the 
client computer (900) 

measuring (603) the time (t) during that the commu- 
nication between the chent computer (900) and the 
server computer (901) is idle, 

displaying (604) a warning to the user if the mea- 
sured time (t) reaches a predetermined firaction 
p^) of the time-out period (T). 
18. Acomputer program product (100/101) for controlling 
HTTP-communication between a client computer (900) and 
a server computer (901), wherein the chent computer (900) 
has a browser (210), the computer program product (100/ 
101) with a client program portion (100) to control a chent 
processor (910) and a server program portion (101) to 
control a server processor (911), characterized in that 

the client program product portion (100) causes the chent 
processor (910) to send (601) a request (230) from the 
chent computer (900) to the server computer (901); 

upon receiving (611) the request (230) by the server 
computer (901), the server program portion (101) 



causes the server processor (911) to allocate (612) a 
resource at the server computer (901), the resource with 
an identifier (350) and a timeout period (T), to return 
(613) a close instruction (360) to the client computer 
(900), the close instruction (360) with the time-out 
period (T) and the identifier (350), to measure (614) the 
time (t) during that communication between the client 
computer (900) and the server computer (901) is idle, 
and to de -allocate (615) the resource (340) when the 
measured lime (t) reaches the time-out period (T); and 

upon receiving (602) the close instruction (360) by the 
client computer (900), the client program portion (100) 
causes the client processor (910) to measure (603) the 
time (t) during that the communication between the 
client computer (900) and the server computer (901) is 
idle, and to display (604) a warning to the user if the 
measured time (t) reaches a predetermined fraction 
(^A) of the time-out period (T). 
19. A method (700) for communication between a chent 
computer (900) and a server computer (901), both comput- 
ers (900, 901) using the hypertext transfer protocol (HTTP), 
the client computer (900) using an HTTP-browser (210); 

the method (700) comprising the following steps: 

sending (720) a first request (230) from the client 
computer (900) to the server computer (901); 

allocating (731) a resource (340) at the server computer 
(901), the resource (340) with an identifier (350); 

returning (732) a predetermined response page to the 
browser (210), the response page carrying the iden- 
tifier (350) and carrying browser instructions; 

as instructed by the response page, periodically sending 
(760) the second requests (240) by the browser (210) 
to the server computer (901), the second requests 
(240) carrying the identifier (350); and 

at the server computer (901), periodically checking 
(770) the arrival of the second requests (240) with 
the identifier (350) from the chent computer (900) 
and de-allocating (780) the resource (340) in case a 
predetermined time period (T) has lapsed since the 
last arrival. 

4c 4c * 4t * 
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